문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 SQL injection (문단 편집) == 방어 방법 == 아마도 [[XSS]]와 상당 부분 겹치겠지만 기본적으로 유저에게 받은 값을 직접 SQL로 넘기면 안 된다. 요즘에 쓰이는 거의 모든 데이터베이스 엔진은 유저 입력이 의도치 않은 동작을 하는 걸 방지하는 escape 함수와 prepared statement[* 직역하면 '준비된 서술'로, SQL 쿼리를 사전에 [[컴파일]]한 뒤 변수만 따로 집어넣어 실행하는 것이다.]를 제공한다. prepared statement 는 변수를 문자열로 바꾸는 것이라 안전하다. 또한 DB에 유저별로 접근 권한과 사용 가능한 명령어를 설정하면 최악의 경우에 SQL injection에 성공하였다고 하더라도 그나마 피해를 최소화할 수 있다. 혹자는 SQL injection은 데이터베이스 [[스키마]]를 알아야 가능한 공격기법이라고 하지만 스키마 구조를 몰라도 SQL injection을 사용하면 스키마 구조를 알아낼 수가 있다.[* 애초에 앞서 설명했듯 JOIN, UNION 구문을 통한 임의 코드 실행이 가능한 공격 방법이다.] 그리고 데이터베이스를 변조하려는 게 아니라 파괴하려는 거라면 와일드카드 문자( * )를 사용해서 그냥 싹 다 지워버리는 공격이 가능. DBMS마다 문법이 다르기 때문에 개발자가 그걸 다 고려해서 코딩하는 방법은 매우 비추천한다. 해당 언어나 프레임워크에서 제공하는 prepared statement라는 방법을 사용하는 게 최선. escape_string 같은 함수를 사용하면 몇몇 군데에서 빼먹거나 하는 실수로 보안 구멍이 생길 수 있다. 그리고 prepared statement는 사용 전에 일부 컴파일돼서 DB 쿼리를 가속시켜주므로 적극적으로 사용하자. 다만 컴파일하는 시간이 있다 보니 변수만 다른 같은 쿼리를 반복적으로 하는 작업에서야 유의미한 속도 향상이 있다. 프로시저(Procedure)라는 쿼리 캡슐화 기능을 쓰거나 최신 프레임워크에서 지원하는 ORM(Object Relational Mapping)을 사용해서 SQL에 직접 접근하지 않는 것도 방법이다(더불어 ORM은 DBMS를 타지 않으므로 DB를 변경해도 그에 따른 공수를 최소화 할 수 있다는 장점도 있다.). 추천되는 방어법은 클라이언트 측의 입력을 받을 웹 사이트에서 자바스크립트로 폼 입력값을 한 번 검증하고[* 이때의 폼 검증은 사용자에게 인젝션에 필요한 특수문자의 사용이 불가능하다고 알리는 용도로, 방어방법과는 관련이 없다는 걸 유의하자.], 서버 측은 클라이언트 측의 자바스크립트 필터가 '''없다'''고 가정하고[* 공격자가 브라우저에서 자바스크립트 사용을 끄거나 폼 페이지를 변조하면 그만이기 때문.]한 번 더 입력값을 필터한다. 이때 [[정규표현식]]등으로 한번 걸러내고, SQL 쿼리로 넘길 때 해당 파라미터를 prepared statement로 입력받고 이를 프로시저[* [[SQL]] 구문을 '함수' 꼴로 묶어 놓은 것이다.]로 처리하는게 좋다. 다음, 쿼리의 출력값을 한 번 더 필터하고([[XSS]] 공격 방어의 목적이 강하다) 유저에게 전송한다. 이렇게 하면 해당 폼에 대해서는 SQL injection 공격이 완전히 차단된다. 물론 이것이 공격 기법의 전부가 아니므로 정보 유출에 민감한 사이트를 운영할 생각이라면 보안 회사의 컨설팅을 꼭 받아야 한다. [[분류:SQL]][[분류:해킹/기법]][[분류:컴퓨터 보안]]저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기